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Method And Apparatus For Use In Relation To 
Verifying An Association Between Two Parties 

Field of the Invention 

The present invention relates to a method and apparatus for use relation to verifying an 
association between two parties by cryptographic techniques; in particular, but not 
exclusively, the present invention relates to a method and apparatus for enabling the 
verification, and/or for verifying, an association between a lower-level trusted authority 
and a higher-level trusted authority in a hierarchy of trusted authorities by using elliptic 
curve cryptography. 

Background of the Invention 

With the ever-increasing spread of electronic communication and electronic identification 
there has been a corresponding increase in demand for cryptographic processes, where 
users require cryptographic processes to enable encryption of data for security purposes 
and/or for the purposes of providing identification. 

Typically encryption keys are certified by trusted authorises and disseminated using digital 
certificates where, to allow wide spread availability of cryptographic processes, a hierarchy 
of trusted authorities exist. Within a hierarchy of trusted authorities a root trusted authority 
issues a digital certificate to a private/public key to a second level trusted authority by 
using the root authorities private key to sign the second level's trusted authorities public 
key and thereby providing confirmation that the second level private key is authorized by 
the root authority. Correspondingly the second level trusted authority issues a digital 
certificate to a different private/public key to a third level trusted authority that is signed 
with the second level's private key and so forth. However, for a user to determine that the 
public key associated with the third level trusted authority is derived with the authority of 
the root trusted authority it is necessary for the user to trace the digital certificates that 
incorporated the various public keys. 

It is desirable to improve this situation. 
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Embodiments of the present invention to be described hereinafter make use of 
cryptographic techniques using bilinear mappings. Accordingly, a brief description will 
now be given of certain such prior art techniques. 

5 

In the present specification, G\ and G2 denote two algebraic groups of prime order q in 
which the discrete logarithm problem is believed to be hard and for which there exists a 
computable bilinear map p, for example, a Tate pairing t or Weil pairing e. Thus, for the 
Weil pairing: 

10 e: G, x G\ > G 2 

where G2 is a subgroup of a multiplicative group of a finite field. The Tate pairing can be 
similarly expressed though it is possible for it to be of asymmetric form: 
t: Gt x Go > Gi 

where Go is a further algebraic group the elements of which are not restricted to being of 
1 5 order q. Generally, the elements of the groups G 0 and G\ are points on an elliptic curve 
though this is not necessarily the case. 

As is well known to persons skilled in the art, for cryptographic purposes, a modified form 
of the Weil pairing is used that ensure p (PJP) ^ 1 where P e G\, however, for 
20 convenience, the pairing is referred to below simply by its usual name without labeling it 
as modified. Further background regarding Weil and Tate pairings and their cryptographic 
uses can be found in the following references: 

- G. Frey, M. Mttller, and H. Ruck. The Tate pairing and the discrete logarithm applied 
to elliptic curve cryptosystems. IEEE Transactions on Information Theory, 

25 45(5):1717-1719, 1999. 

- D. Boneh and M. Franklin. Identity based encryption from the Weil pairing. In 
Advances in Cryptology - CRYPTO 2007, LNCS 2139, pp. 213-229, Springer- Verlag, 
2001. 

30 For convenience, the examples given below assume the use of a symmetric bilinear map 

{p: G\ x Gi > G 2 ) with the elements of G\ being points on an elliptic curve; however, 

these particularities, are not to be taken as limitations on the scope of the present invention. 
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As the mapping between Gi and G2 is bilinear exponents/multipliers can be moved around. 
For example if a,b,ce F q and P, Q e G\ then 

t(aP, bQf = t{aP, cQ) b = t(bP, cQf = t(bP, aQf = t(cP, aQ) b = t(cP, bQf 
5 = t(abP, Qf = tiabP, cQ) = t{P, abQf = t{cP, abQ) 

= HpibcP, Q) = t(P, abcQ) = t(P, Q) abc 



Additionally, the following cryptographic hash functions are defined: 

10 Hi : {0,1}* >d 

H 2 :{0,1}* >F q 

H 3 :G 2 >{0,1}* 

A normal public/private key pair can be defined for a trusted authority: 
1 5 the private key is s where seF, 

the public key is (P, R) where P e G\ and R e Gl , with R=sP 



Additionally, an identifier based public key / private key pair can be defined for a party 
with the cooperation of the trusted authority. As is well known to persons skilled in the art, 

20 in "identifier-based" cryptographic methods a public, cryptographically unconstrained, 
string is used in conjunction with public data of a trusted authority to carry out tasks such 
as data encryption or signing. The complementary tasks, such as decryption and signature 
verification, require the involvement of the trusted authority to carry out computation based 
on the public string and its own private data. Frequently, the string serves to "identify" the 

25 intended message recipient and this has given rise to the use of the label "identifier-based" 
or "identity-based" generally for these cryptographic methods. However, depending on the 
application to which such a cryptographic method is put, the string may serve a different 
purpose to that of identifying the intended recipient and, indeed, may be an arbitrary string 
having no other purpose than to form the basis of the cryptographic processes. 

30 Accordingly, the use of the term "identifier-based" herein in relation to cryptographic 
methods and systems is to be understood simply as implying that the methods and systems 
are based on the use of a cryptographically unconstrained string whether or not the string 



serves to identify the intended recipient. Furthermore, as used herein the term "string" is 
simply intended to imply an ordered series of bits whether derived from a character string, 
a serialized image bit map, a digitized sound signal, or any other data source. 

5 In the present case, the identifier-based public / private key pair defined for the party has a 
public key Q ro and private key 5© where g ro , Sid e G\. The trusted authority's normal 
public/private key pair {P,R I s) is linked with the identifier-based public/private key by 

S m = sQ m and 0 ro = H x (ID) 
where ID is the identifier string for the party. 

10 

Some typical uses for the above described key pairs will now be given with reference to 
Figure 1 of the accompanying drawings that depicts a trusted authority 1 0 with a public key 
(P, sP) and a private key s. A party A serves as a general third party whilst for the 
identifier-based cryptographic tasks (IBC) described, a party B has an IBC public key (9id 
1 5 and an IBC private key Sjd. 

Standard Signatures (see dashed box 2) : The holder of the private key s (that is, the trusted 
authority 1 or anyone to whom the latter has disclosed s) can use 5 to sign a bit string; more 
particularly, where m denotes a message to be signed, the holder of s computes: 
20 V = sH x (m). 

Verification by party A involves this party checking that the following equation is satisfied: 
t(P,V) = t(R,H x (m)) 

This is based upon the mapping between G\ and G2 being bilinear exponents/multipliers, as 
25 described above. That is to say, 
t(P,V) = t(P,sH x (m)) 
= t(P,H x (m)) s 
= t{sP,H x (m)) 
= t(R,H x {m)) 
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Identifier-Based Encryption (see dashed box 3) : - Identifier based encryption allows the 
holder of the private key 5id of an identifier based key pair (in this case, party B) to decrypt 
a message sent to them encrypted (by party A) using B's public key Qjd . 

More particularly, party A, in order to encrypt a message m, first computes: 
U=rP 

where r is a random element of F 9 . Next, party A computes: 

V=m® H 3 (t(R, rQm)) 
Party A now has the ciphertext elements U and V which it sends to party B. 

Decryption of the message by party B is performed by computing: 
V® H3 (t(U, Sid)) = V® H 3 (t(rP, sQ w )) 

= v® hmp, QvT) 

= V ® H 3 (t(sP, rQro)) 
= V ® H 3 (t(R, rQ m )) 



Identifier-Based Signatures (see dashed box 4) : 



pairing can be implemented. For example: 

Party B first computes: 

r = t(S ]D ,Pf 
where k is a random element of F g . 



- Identifier based signatures using Tate 



Party B then apply the hash function H 2 to m || r (concatenation of m and r) to obtain: 

h=H 2 (m\\r). 
Thereafter party B computes 

U=(k-h)SiD 

thus generating the output U and h as the signature on the message m. 

Verification of the signature by party A can be established by computing: 
r > = t(U,P)-t(Q m ,Rf 
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where the signature can only be accepted if h=H 2 (m \\ r r ). 

It will be recalled that the problem discussed at the outset was how a third party could 
5 verify the associations between trusted authorities arranged in a hierarchy without having 
to follow a trail of certificates. In fact, the above-described IBC encryption/decryption 
method offers one possible solution. Consider the situation where a trusted authority at one 
level in the hierarchy has an EBC public key Q ro / private key Sid pair with the private key 
being provided by a trusted authority in the next level up on the basis of the ID of the 

1 0 lower- level trusted authority and the private key s of a normal public key (P, sP) I private 
key 5 pair held by the higher-level trusted authority. A third party could then check that the 
lower-level trusted authority was associated with the higher level one by an IBC-based 
challenge/response mechanism. More particularly, the third party could encrypt a nonce 
(random number) using both the public key element sP of the higher- level trusted authority 

1 5 and the IBC public key Q ro of the lower-level trusted authority. The third party sends the 
encrypted nonce to the lower-level trusted authority and asks it to decrypt and return the 
nonce - the lower-level trusted authority will only be able to do this if it has (or can get) 
the key <Std( = sQk>) from the higher-level trusted authority. Thus, if the lower-level trusted 
authority can return the decrypted nonce, the association between the lower-level trusted 

20 authority and the higher level trusted authority is proved. Whilst this approach is viable, it 
involves an exchange of messages between the third party and the lower-level trusted 
authority and also (if the lower-level trusted authority does not already have its IBC 
private key) between the lower-level trusted authority and the higher-level trusted 
authority. In many situation this may either not be possible or undesirable- for example, 

25 the third party may wish to check the association between the trusted authorities offline or 
the third party may not wish to let it be known that it is carrying out the check. 

It is an object of the present invention to provide a way of checking the association 
between two parties that obviates at least some of the difficulties noted above. 

30 
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Summary of the Invention 

According to a first aspect of the present invention, there is provided a method of enabling 
a third party to verify an association between a first party associated with a first element, of 
a first algebraic group, and a second party associated with a second element, of a second 
algebraic group, formed from an identifier string of the second party, wherein: 

- there exists a computable bilinear map for the first and second elements; 

- the first party has a first secret and computes a first product from the first secret and the 
first element; 

- the second party has both a second secret, and a shared secret provided by the first 
party as the product of the first secret and the second element; 

- the second party computes first, second and third verification parameters as the product 
of the second secret with said shared secret, the second element and the first element 
respectively. 

Using the non-secret data elements and a function p providing the bilinear mapping, a third 
party can verify the existence of an association between first and second parties by: 

- computing the second element from the identifier string of the second party; 

- carrying out a first check: 

p (third verification parameter, computed second element) 

= p (first element, second verification parameter) 

- carries out a second check: 

p (first element, first verification parameter) 

= p (first product, second verification parameter) 
the association between the first and second parties being treated as verified if both checks 
are passed. 

According to a second aspect of the present invention, there is provided a method of 
verifying an association between a first party associated with a first element, of a first 
algebraic group, and a second party associated with a second element, of a second algebraic 
group; the first and second elements being such that there exists a bilinear mapping p for 
these elements; the method comprising carrying out the following operations: 
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- receiving both data indicative of said first element, and a first product formed by the 
first party from a first secret and the first element; 

- receiving in respect of the second party both an identifier string, and first, second and 
third verification parameters; 

5 - computing the second element from the identifier string of the second party; 

- carrying out a first check: 

p (third verification parameter, computed second element ) 

= p (first element, second verification parameter) 

- carrying out a second check: 

10 p (first element, first verification parameter) 

= p (first product, second verification parameter) 
the association between the first and second parties being treated as verified if both checks 
aire passed. 

1 5 According to a third aspect of the present invention, there is provided a method of enabling 
verification of an association between parties, the method comprising: 

- generating a first private key and public key for a first party; 

- generating a second private and public key for a second party wherein the second 
private key is derived from the first private key and second public key; and 

20 - generating a third private key for the second party that is used in association with the 
first public key, the second private key and the second public key to form a first 
cryptographic parameter, a second cryptographic parameter and a third public key 
respectively. 

2 5 The present invention also encompasses apparatus and computer program products both for 
providing verification parameters enabling verification of an association between two 
parties, and for carrying out a verification check using these parameters. 
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Brief Description of the Drawings 

Embodiments of the invention will now be described, by way of non-limiting example, 
with reference to the accompanying diagrammatic drawings, in which: 
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. Figure 1 is a diagram showing prior art cryptographic processes based on elliptic 

curve cryptography using Tate pairings; 
. Figure 2 is a diagram illustrating a first embodiment of the invention illustrating for 

generalized first and second parties, how a third party can verify an 

association between first and second parties; 
. Figure 3 is a diagram of a second embodiment involving a hierarchy of a first-level 

trusted authority and a second-level trusted authority; and 
. Figure 4 is a diagram of a third embodiment involving an n- level hierarchy of 

trusted authorities. 



Best Mode of Carrying Out the Invention 

Considering first the situation where there is an association between a first party and a 
second party which the second party would like to be able to prove to a third party; the 
1 5 nature of the association concerned is not relevant to the present discussion but could, for 
example, be a trust relationship (e.g. the second party is trusted to act on behalf of the first 
party in respect of certain matters) or simply a biological relationship (e.g. the first party is 
a parent and the second is a child of the first party). 

20 In order to enable the second party to prove this association, the first party provides the 
second party with a secret, herein referred to as a "shared secret", though there is no 
requirement on the first party to keep a copy of this shared secret after giving it to the 
second party. The nature of the shared secret is such that it enables the second party to 
prove its association with the first party without giving away the shared secret. 
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According to the present invention, the above-described arrangement is enabled by the use 
of bilinear mappings as will now be explained with reference to embodiments based on 
modified Tate pairings (though, of course, other pairings such as modified Weil pairings 
can alternatively be used). The notations and definitions given in the introductory portion 
of the present specification also apply to what follows. 
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The first party has its own secret s\ and an associated point P on an elliptic curve. The first 
party makes P and the combination s\P(=R) publicly available in any suitable manner. The 
second party also has its own secret s 2 and an associated point Q on the same elliptic curve 
as P. The second party makes Q and the combination s 2 Q publicly available in any suitable 
5 manner. It will be appreciated that reference to an element being made publicly available 
simply means making it available to third parties who have an interest and right to know 
the element and does not necessarily imply unrestricted distribution. 

The second party is provided with s\Q by the first party as the shared secret that is to be 
1 0 used in establishing to the third party the association between the second party and the first 
party. In order to keep the shared secret S\ Q secret whilst providing the third party with the 
information it needs to verify the association between the first and second parties, the 
second party combines s\Q with s 2 and makes the resulting combination s\s 2 Q public. 



15 Recapping so far, the elements associated with the first and second parties are: 
First party: 

Secret data: s\ 

Public data: P, R(=s { P) 
Second party: 

20 Secret Data: s 2 , syQ 

Public data: Q, S\s 2 Q, s 2 Q 



It is assumed that the third party reliably knows P and R(=s\P), the public data of the first 
party. The third party has also received, in respect of the second party: the point Q; an 
25 element, herein called X, that is purportedly s\s 2 Q; and an element, herein called Y, that is 
purportedly s 2 Q. In order to check whether X truly does contain s\, the third party checks 
the following : 

t(P, X) = t(R, Y) Test 1 

Because R=s\P, the above will only be valid ifXis equal to si Y. This would prove that the 
30 second party must have a shared secret containing s\ which only it and the first party know 
(thus proving the association between the parties) were it not for the possibility that, since 
s\P is public, the second party could have constructed Q as mP, where m e F q , and then 
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used m, s 2 and siP to construct Xas s\s 2 mP and Y as s 2 mP. In other words, if the second 
party can construct its Q from P then, it can pass Test 1 without needing to ask for a shared 
secret from the first party. 

5 It is therefore necessary for the third party to be satisfied that Q has not been formed by 
multiplying P by m (it being appreciated that because the discrete logarithm problem is 
hard, the third party cannot discover if Q of the form mP — though, of course, if m—\ , this 
will be apparent). To this end, the point Q is required to be derived from an identifier string 
TD using the map-to-point hash function H\ because in this case even if Q happened to be 
10 equal to mP (which is highly unlikely), the second party would neither be aware of this nor 
able to separate out m and use it to generate anXof the form s\s 2 mP. It is not, of course, 
possible for the second party to work backwards from a value of m to produce the string ID 
that would give rise to m using the map-to-point function. 

15 To emphasise the fact that Q originates from an identifier, it is suffixed with "ID" in the 
following discussion; thus: 

Qjd=HxQD) 

where the identifier string ID can be any string and typically, though not necessarily, serves 
to identify the second party in plain language. 

20 

So now if the second party makes public the string ID rather than (or in addition to) Qid, 
the third party can use the string ID to form the point Qio thereby re-assuring itself that the 
second party has not used a value m to form Q as mP. However, the third party also needs 
to be able to link this legitimate Qjo to the elements used in Test 1 - in particular, the third 

25 party needs to be sure that the element 7 contains the legitimate Qm derived from ID. To 
this end, the third party must carry out a second test for which purpose the second party 
must provide a further quantity, herein called Z, that is purportedly equal to s 2 P. The 
second test is of the following form: 

t(Z, Qjo)= t(P, Y) Test 2 

30 If this is true, then the second party knows that 7 must contain Qxd- 
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The above test (Test 1) is now therefore adequate to prove that the second party does 
indeed have a shared secret of the form sxQro which must have been provided by the first 
party, thereby proving there is an association between the first and second parties. 



5 Recapping, and as shown in Figure 2, the elements associated with the first and second 
parties 5, 6 are: 
First party 5: 

Secret data: s\ 
Public data: P, R=s x P 
10 Second party 6 : 

Secret data: s 2 , 

Public data: ID, X=s x s 2 Q ]D , Y=s 2 Qn>, Z= s 2 P 
and the third party 7 carries out the following: 
Qio = map-to-point H\(JD); 
15 Test 2; 

Test 1. 



The requirements for the third party to be able to verify the association between the first 
and second parties (respectively higher-level and lower-level parties in the association 
20 hierarchy) can thus be expressed as follows: 

- the first party must have a public key (P, R) I private key s\ key pair where R=s\P ; 

it may be noted that P could be based on an identity string for the first party by using 
the map-to-point hash H\. 

- the second party must have an IBC public key ID / private key si£?id key pair where Qyd 
25 -Hi(ID). 

- using a secret s 2 the second party must form three public verification parameters (X, Y, 
Z) by multiplying by s 2 : 

- the point P that is part of the public key of the first party, 

- the point Q\£> of the second party, 

30 - the private part s\ Qjd of the second party's IBC key pair. 

In applying the two Tests 1 and 2, the point P is the point that is part of the public key of 
the first (higher-level) party, the other part of the key being /?, whilst the point Q lD is the 
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point derived from the identity of the second (lower-level) party using the map-to-point 
hash function H\ and the parameters X, Y and Z are all supplied by the second party. 

Other ways of characterising the parameters referred to above as the "verification 
5 parameters" are also possible; for example, it may be noted that two of these parameters, 
namely Y(=s 2 £?id) and Z(= sjP) can each be viewed as part of the public key of a respective 
standard public/private key pair that involves the point concerned and has a private key of 
s 2 . 

10 

Figure 3 illustrates the application of the foregoing to an hierarchical arrangement of two 
trusted authorities 60 and 70 where the latter has issued a user 80 with an IBC private key. 

More particularly, Figure 3 shows a first computer entity 1 0, a second computer entity 20, a 
15 third computer entity 30 and a fourth computer entity 40 connected via a network 50, for 
example the Internet. The first computer entity 1 0 represents a first trusted authority 60, for 
example a company, the second computer entity 20 represents a second trusted authority 
70, for example a division within the company and the third computer entity 30 represents 
a user 80, for example a worker within the company. The fourth computer entity 40 
20 represents, for example, a business partner 90 of the company that wishes to interact with 
the user 80. 

The first, second, third and fourth computer entities 10, 20, 30, 40 are conventional 
program-controlled computing devices though specialised hardware may be provided to 
25 effect particular cryptographic processes. 

The first computer entity 10 and second computer entity 20 form a trusted authority 
hierarchy in which the first computer entity 10 acts as a root, or first level, trusted authority 
60 and the second computer entity 20 acts as a second level trusted authority 70. The first- 
30 level trusted authority 60 has a standard public key (P, Rta\) I private key^i key pair where 
#tai= s\P. The second-level trusted authority 20 has an IBC public/private key pair the 
private key Sta2 of which has been generated by the first-level trusted authority 60 using its 
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private key s x and Qtaz, where Q TAZ =H\(JA2) and "TA2" is an identity string associated 
with the second-level trusted authority 70. Table 1 sets out the keys held by the first-level 
and second-level trusted authorities 60 and 70. 



Entity 


Standard 
Private Key 


Standard 
Public key 


ID Based 
Private Key 


ID Based 
Pubic key 


First-level TA 


S\ 


P, R TM (=s x P) 






Second-level TA 






St\2=S\Q,TA2 


0TA2=#l(TA2) 
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Table 1 

Once in the possession of the LBC private key Sjai (the "master private key") the second- 
level trusted authority 70 is able to produce a set of verification parameters X, Y and Z 

10 enabling a third party to verify, without further interaction with the first-level trusted 
authority and without the need for digital certificates, that the private key of the IBC 
public/private key pair of the second-level trusted authority 70 could only have been 
generated by the first-level trusted authority 60. More particularly, the second-level trusted 
authority 70 selects a random number r where r e F ? ; the random number r is a "pseudo- 

1 5 master private key". Once the pseudo-master key has been selected the second-level trusted 
authority 70 generates the following public verification parameters: 

rsiQ-vAi , rQjAi and rP 
that respectively correspond to the parameters X, Y and Z of the above-described Tests 1 
and 2. 

20 

It should be noted that even though in the above example the second-level trusted authority 
70 has created a single pseudo-master private key, the second-level trusted authority 70 
could generate any number of pseudo-master private keys. 

25 It may also be noted that the second-level trusted authority 70 is likely also to have one or 
more standard public/private key pairs. For example, the pseudo-master private key r could 
be used as the private key and combined either with P or Q ro or another point in Gi not 
computed from an existing point, to form a corresponding public key. Alternatively, a 



15 

completely separate private key s 2 could be generated where s 2 e F 9 and used with P or Qm 
or another point in Gi not computed from an existing point, to form a corresponding public 
key. 

5 The user 80 registers with the second trusted authority 70 to obtain an associated IBC 
private key for the user's public key, where the user's public key could be any form of 
identifier, for example the user's name 'Bob', and the map-to-point hash /f t (Bob) of this 
identifier maps to a point Qeob in G\. The IBC private key provided to the user 80 is a 
combination of the user's public key and the second-level trusted authority's pseudo 
10 private key i.e. the user's private key is rQ Bo b- 

To send an encrypted message to the user 80, the third-party business partner 90 can now 
use the IBC public key of the user 80 and the public key of the second-level trusted 
authority 70 used by user 80; in doing this, the third party 90 can be sure that the user will 
15 only be able to decrypt the message if the user is known to the second-level trusted 
authority 70 since the IBC private key needed for decryption must be provided by that 
authority. 

The third party 90 can also verify that the second-level trusted authority 70 (company 
20 division) is associated with the first-level trusted authority (company). To do this, the third 
party 90 uses the identity "TA2" and public verification parameters rs \Qtki , rQ T A2 and rP 
of the second-level trusted authority 70, together with the public key P, Rt A i(=s\P) of the 
first-level trusted authority 60, to carry out the Tests 1 and 2 described above with respect 
to Figure 2. More particularly: 
25 - the third party 90 first forms Qtai from the identity string "TA2" using the map-to- 
point hash function H\ \ 

- the third party 90 carries out Test 2 by checking 

t(Z,Q TA2 )=t(P,Y) 

where Z= rP and Y= yQxkl and Q T A2 is the element just formed from the identity 
30 "TA2"; this check, if passed, confirms that the element Y contains Qta2 

- the third party 90 carries out Test 1 by checking 

t(P, X) = t(R JAh Y) 
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where R TA \=siP and X= tsxQxkl, this check, if passed, confirms thatXmust contains 
which the second-level trusted authority 70 must have obtained in a non-public element 
from the first-level trusted authority 60. 

Of course, because the second-level trusted authority has published its point Qtpo. (or the 
underlying identifier "TA2") as well as the element rQi A z thereby providing a standard 
public/private key pair, it would be possible for the user 80 itself to produce a set of 
verification parameters to enable the third party 90 to verify the existence of an association 
between the user 80 and the second-level trusted authority 70 without needing to send a 
message to the user. To produce the required verification parameters the user 80 picks a 
random number r B where r B e F 9 and generates the parameters: 

rnrQiiob, r B QBob and r B £>TA2 
respectively corresponding to the parameters X, Y and Z. In this case, in the Tests 1 and 2, 
the element P is, of course, replaced by Q\pa and the element R by rQj A2 as Qtaz is now 
the point associated with the higher-level party. In fact, where the second-level trusted 
authority has provided one or more other standard public/private key pairs, the public 
values of any such pair can be used for the elements P and R in the previously stated forms 
of the Tests. 

20 Figure 4 of the accompanying drawings illustrates for an n-level hierarchy of trusted 
authorities TA1 to TAn, a possible organisation of keys and verification parameters. In this 
example, each trusted authority such as authority TAi (where Ki<=n) has: 

- a standard public/private key pair, the private key of this key pair being a secret s, and 
the public key being (P it SiP,) where P,=//i("TAz") that is, the map-to-point hash of the 

25 identity of the authority; 

- an IBC key pair, the public key of this key pair being the identity TAi of the trusted 
authority and the secret key being the product of the map-to-point hash of this identity 
and the secret s,.; of the next level up trusted authority; 

- two additional verification parameters SiSj./Pi and SiPi.j (corresponding to X and Z 
30 above, the verification parameter Y= SiPt already being present in the public key of the 

standard key pair). 
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The root trusted authority TA1 simply has a standard public key(P/,s;F)/private keys; key 
pair. 

With this hierarchy, it is possible to verify the association between each parent/child 
5 pairing of trusted authorities in the hierarchy thereby enabling a check to be made that any 
non-root trusted authority, from the lowest level (or leaf) authority upwards, is associated 
with the root trusted authority. 

It will be appreciated that many variants are possible to the above described embodiments 
10 of the invention. 



